1. Field of the Invention
The present invention relates to the field of IP audio conferencing over a computer communications network, and more particularly audio packet throttling based upon server processing capabilities.
2. Description of the Related Art
The advent of the modern computer communications network has revolutionized the manner in which data is exchanged and the speed at which data is exchanged. At the outset of the modern computing era, only the most basic of information could be exchanged between computing devices due to the limitations of network bandwidth and the perceived unreliability of the underlying data exchange media. Today, however, substantial advances in the underlying infrastructure of global computer networks permit the exchange of a wide variety of data ranging from simple text messages to full motion video and audio.
The exchange of real time data such as audio speech involves specific considerations not applicable to the exchange of other types of time insensitive data. In this regard, while the slight delay in the arrival of packets in a text message can be inconsequential in respect to the accurate and efficient delivery of the text message, slight delays in the delivery of real time data such as speech can render the ultimately delivered data unusable for its intended purpose. To account for the time sensitivity of real time data, several real time delivery technologies have been proposed to manage the transport and delivery of real time data. The Real Time Protocol (RTP) represents one example of a real time delivery technology.
RTP is a thin protocol providing support for applications with real-time properties, including timing reconstruction, loss detection, security and content identification. Specifically, RTP provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, time-stamping and delivery monitoring. Applications typically run RTP on top of the universal datagram protocol (UDP) to make use of its multiplexing and checksum services. In that case, both protocols contribute parts of the transport protocol functionality.
RTP can include a control protocol referred to as the real time control protocol (RTCP). RTCP is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP several functions, the primary function of which is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols.
Notably, RTCP can be used to monitor network conditions so that both sender and receiver can make adjustments to their respective systems to adapt to network conditions. In particular, U.S. Pat. No. 6,643,496 to Shimoyama et al. teaches the adjustment of the packet transmission rate of real time data using RTP over RTCP where a target transmission rate cannot be achieved, or where it is judged that packet loss has occurred. Similarly, U.S. Pat. No. 6,858,613 to Murphy teaches the throttling of audio packets based upon the capabilities of a gateway processing facility encoding the audio packets such that a trade-off is made between packet size and a number of packets transmitted.
Notably, some modern audio conferencing servers employ RTP packet switching to provide multiple streams of audio to participants in a multi-point audio conference. Specifically, the server evaluates the data received from clients and decides which packets should be forwarded to the IP audio clients. The clients are then responsible for mixing the streams received from the server and presenting the resulting audio to the user. This reduces the load on the server, which is acting primarily as a router whereas the clients themselves and not the server encode the audio packets in performing central processing unit (CPU) intensive audio mixing.
Generally, the server can be configured to forward a fixed number of audio streams to the clients. However, forwarding a fixed number of audio streams creates several problems. First, on the server higher values of the fixed number of audio streams will result in a better conferencing experience, but will limit the scalability of the server. Conversely, lower values of the fixed number will improve server scalability, but will adversely impact the quality of the conferencing experience. Accordingly, administrators of a server providing an audio conferencing facility are forced to make this trade-off ahead of time, as part of configuration. Another problem results on the client, where higher values of the fixed number can provide an unacceptable experience for clients on lower speed connections due to packet loss while clients on broadband connections will not be affected. Thus, administrators will tend to choose a lower value to handle the “common denominator” case, so all clients suffer to ensure an acceptable experience for those with lower speed connections.